Internet Engineering Task Force (IETF) M. Zhang 
Request for Comments: 8397 D. Eastlake 3rd 
Category: Standards Track Huawei 


ISSN: 2070-1721 R. Perlman 
Dell EMC 


H. Zhai 

JIT 

D. Liu 

China Telecom Co., Ltd 
May 2018 


Transparent Interconnection of Lots of Links (TRILL) Multilevel 
Using Unique Nicknames 


Abstract 


TRILL (Transparent Interconnection of Lots of Links) routing can be 
extended to support multiple levels by building on the multilevel 
feature of IS-IS routing. Depending on how nicknames are managed, 
there are two primary alternatives to realize TRILL multilevel: the 
unique nickname approach and the aggregated nickname approach as 
discussed in RFC 8243. This document specifies a unique nickname 
approach. This approach gives unique nicknames to all TRILL switches 
across the multilevel TRILL campus. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8397. 
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Copyright (c) 2018 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(https://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Les 


Introduction 


The multiple-level feature of [IS-IS] can increase the scalability of 
TRILL as discussed in [RFC8243]. However, multilevel IS-IS needs 
some extensions to support the TRILL multilevel feature. The two 
most significant extensions are how TRILL switch nicknames are 
managed and how distribution trees are handled [RFC8243]. 


There are two primary alternatives to realize TRILL multilevel 
[RFC8243]. One approach, which is referred to as the "aggregated 
nickname" approach, involves assigning nicknames to the areas, and 
allowing nicknames to be reused in different areas by having the 
border TRILL switches rewrite nickname fields when entering or 
leaving an area. For more description of the aggregated nickname 


approach, one can refer to [RFC8243] and [SingleN]. The other 
approach, which is referred to as the "unique nickname" approach, is 
specified in this document. The unique nickname approach gives 


unique nicknames to all the TRILL switches in the multilevel campus 
by having the TRILL switches at the Level 1 / Level 2 border 
advertise into the Level 1 area those nicknames are not available for 
assignment in that area and advertising into the Level 2 area those 
nicknames that are used by the Level 1 area so that other areas 


cannot use them anymore. The advertising of Level 1 nicknames 
informs the rest of the campus how to reach the nicknames residing in 
that area. In this document, protocol extensions that support such 


advertisement are specified. 


Each RBridge in a unique nickname area calculates two types of trees: 
local distribution trees and global distributions trees. For multi- 
destination traffic that is limited to an area, the packets will be 
flooded on a local distribution tree. Otherwise, the multi- 
destination packets will be flooded along a global distribution tree. 


In the unique nickname approach, nicknames are globally valid so that 
border RBridges do not rewrite the nickname field of TRILL data 
packets that transition between Level 1 and Level 2, as border 
RBridges do in the aggregated nickname approach. If a border RBridge 
is a transit node on a forwarding path, it does not learn MAC 
addresses of the TRILL data packets forwarded along this path. 
Testing and maintenance operations that originate in one area and 
terminate in a different area are also simplified [RFC8243]. For 
these reasons, the unique nickname approach might realize simpler 
border RBridges than the aggregated nickname approach. However, the 
unique nickname approach is less scalable and may be less well suited 
for very large campuses. 
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2. Acronyms and Terminology 


Border RBridge: An RBridge that is located on the border between two 
or more RBridge areas. 


Data Label: VLAN or FGL [RFC7172] 
IS-IS: Intermediate System to Intermediate System [IS-IS] 
RBridge: A device implementing the TRILL protocol. 


TRILL: Transparent Interconnection of Lots of Links or Tunneled 
Routing in the Link Layer [RFC6325]. 


TRILL switch: An alternative name for an RBridge. 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


3. Data Routing 


Area X level 2 Area Y 


| 27 | | | | aa | 


Figure 1: An Example Topology for TRILL Multilevel 


Figure 1 is adapted from the example topology of [RFC8243], where S 
is Source, and D is Destination. 


The routing processes are described in the following two subsections. 
3.1. Unicast Routing 


The plain RBridge RB27 has a different view of the topology of the 
TRILL campus than its border RBridge RB2. For an outward path that 
reaches an RBridge not in the same area (say, RB44), RB27 calculates 
the segment of the path in Area X, the border RBridge RB2 calculates 
the segment in Level 2, while the border RBridge to the destination 
area, RBridge RB3, calculates the segment from itself to RB44. 
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Let us say that S transmits a frame to destination D and let us say 
that D’s location is learned by the relevant TRILL switches already. 
These relevant switches have learned the following: 


1) RB27 has learned that D is connected to nickname 44. 
2) RB2 has learned that nickname 44 is accessible through RB3. 


The following sequence of events will occur: 


- S transmits an Ethernet frame with source MAC = S and destination 
MAC = D. 


- RB27 encapsulates with a TRILL header with ingress RBridge 
nickname 27, and egress RBridge nickname 44 producing a TRILL Data 
packet. 


—- RB2 has announced in the Level 1 IS-IS instance in Area X that it 
owns all nicknames of other areas, including 44. Therefore, IS-IS 
routes the packet to RB2. 


- The packet is forwarded through Level 2, from RB2 to RB3, which 
has advertised, in Level 2, it owns the nickname 44. 


- RB3, when forwarding into Area Y, does not change the ingress 
nickname 27 or the egress nickname 44. 


- RB44, when decapsulating, learns that S is attached to nickname 
27. 


3.2. Multi-destination Routing 


The scope of Multi-destination routing is defined by the tree root 
nickname. A tree with a Level 2 tree root nickname is global, anda 
tree with a Level 1 tree root nickname is local. See Section 4.2 for 
the Level 1 and Level 2 nickname allocation. 


Border RBridges announce the global trees to be calculated only for 
those Data Labels that span across areas. APPsub-TLVs as specified 
in Section 3.2 of [RFC7968] will be advertised for this purpose. 
Based on the Data Label, an ingress RBridge can determine whether a 
global tree or a local tree is to be used for a TRILL multi- 
destination Data packet. 


If there are legacy TRILL switches that do not understand the APPsub- 
TLVs for tree selection, configuration MUST guarantee that Data 
Labels [RFC7172] being used globally in Level 2 are disabled on these 
legacy TRILL switches. (Otherwise, the legacy TRILL switches might 
use local trees for multi-destination traffic with a global scope.) 
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These legacy TRILL switches may use global trees to flood multi- 
destination packets with a scope of the local area. Those global 
trees MUST be pruned at the border TRILL switches based on Data 
Labels. 


3.2.1. Local Distribution Trees 


The root RBridge RB1 of a local distribution tree resides in the 
area. RBridges in this area calculate this local tree based on the 
link state information of this area, using RB1's nickname as the 
root. Protocol behaviors for local distribution trees have been 
specified in Section 4.5 of [RFC6325]. The sole difference is that 
the local distribution tree spans this area only. A multi- 
destination packet with an egress nickname of the root RBridge of a 
local tree MUST NOT be leaked into Level 2 at the border RBridge. 


3.2.2. Global Distribution Trees 


Within Level 2, the RBridge with the highest tree root priority 
advertises the set of global trees by providing a list of Level 2 
RBridge nicknames as defined in Section 4.5 of [RFC6325]. 


According to [RFC6325], the RBridge with the highest root priority 
advertises the tree roots for a Level 1 area. There has to be a 
border RBridge with the highest root tree priority in each area so 
that it can advertise the global tree root nicknames into the area. 
Also, this border RBridge MUST advertise the set of local 
distribution trees by providing another set of nicknames. Since 
nicknames of global tree roots and local tree roots indicate 
different flooding scopes, these two sets MUST NOT overlap. Ifa 
border RBridge has been assigned both as a global tree root anda 
local tree root, it MUST acquire both global tree root nickname (s) 
and local tree root nickname(s). However, non-border RBridges in an 
area do not differentiate between a global tree root nickname and a 
local tree root nickname. 


Suppose RB3 is the RBridge with the highest tree root priority within 
Level 2, and RB2 is the highest tree root priority in Area X. RB2 
advertises in Area X that nickname RB3 is the root of a distribution 
tree. Figures 2 through 5 illustrate how different RBridges view the 
global distribution tree. 
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RB2, RB3, Rb, Rc, Rd, Re, Rk, RB44 


RB27 o 
Figure 2: RB27's View of the Global Distribution Tree 


RB3,Rk,RB44 
Q 


RB27 o 


Figure 3: RB2’s View of the Global Distribution Tree 


R27,Rx,Rz,RB2 O 


Figure 4: RB3’s View of the Global Distribution Tree 
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RB3, RB27,RBx,RBz, RB2, Rb, Rc, Rd, Re 
o 


o Rk 
\ 
o RB44 


Figure 5: RB44’s View of the Global Distribution Tree 


The following sequence of events will occur when a multi-destination 
TRILL Data packet is forwarded using the global distribution tree: 


- RB27 produces a multi-destination (M bit is one) TRILL Data packet 
with ingress RBridge nickname 27 and egress RBridge nickname 3. 
RB27 floods this packet using the segment of the global 
distribution tree that resides in Area X. 


- RB2, when flooding the packet in Level 2, uses the segment of the 
global distribution tree that resides in Level 2. 


- RB3, when flooding the packet into Area Y, uses the segment of the 
global distribution tree that resides in Area Y. 


- The multicast listener RB44, when decapsulating the received 
packet, learns that S is attached to nickname 27. 


4. Protocol Basics and Extensions 
4.1. Multilevel TRILL Basics 


Multilevel TRILL builds on the multilevel feature of [IS-IS]. Border 
RBridges are in both a Level 1 area and in Level 2. They establish 
adjacency with Level 1 RBridges as specified in [RFC7177] and 
[RFC6325]. They establish adjacency with Level 2 RBridges in exactly 
the same way except that (1) for a LAN link, the IS-IS Hellos used 
are Level 2 Hello PDUs [IS-IS] and (2) for a point-to-point link, the 
Level is configured and indicated in flags in the point-to-point 
Hello. The state machines for Level 1 and Level 2 adjacency are 
independent, and two RBridges on the same LAN link can have any 
adjacency state for Level 1 and, separately, any adjacency state for 


Level 2. Level 1 and Level 2 link state flooding are independent 
using Level 1 and Level 2 versions of the relevant IS-IS PDUs (LSP, 
CSNP, PSNP, FS-LSP, FS-CSNP, and FS-PSNP [RFC7356] [RFC7780]). Thus, 


Level 1 link state information stays within a Level 1 area and Level 
2 link state information stays in Level 2 unless there are specific 
provisions for leaking (copying) information between levels. This is 
why multilevel can address the TRILL scalability issues as specified 
in Section 2 of [RFC8243]. 
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The former "campus wide" minimum acceptable link size Sz is 
calculated as before: by Level 1 RBridges (including border RBridges) 
using the originatingLSPBufferSize advertised in the Level 1 LSP so 
it is area local in multilevel TRILL. A minimum acceptable link size 
in Level 2, called Sz2, is calculated by the RBridges participating 
in Level 2 in the same way as Sz is calculated but using the 
originatingLSPBufferSize distributed in Level 2 LSPs. 


4.2. Nickname Allocation 


Level 2 RBridges contend for nicknames in the range from 0xF000 
through OxFFBF the same way as specified in [RFC6325]: using Level 2 
LSPs. The highest-priority border router for a Level 1 area should 
contend with others in Level 2 for blocks of nicknames for the range 
from 0x0001 to OxEFFF. Blocks of 64 aligned on boundaries of 
multiples of 64 are RECOMMENDED in this document. 


The nickname contention in Level 2 will determine which blocks of 
nicknames are available for an area and which blocks of nicknames are 
used elsewhere. The NickBlockFlags APPsub-TLV as specified in 
Section 4.3 will be used by the border RBridge(s) to announce the 
nickname availability. 


4.3. Nickname Announcements 


Border RBridges need to exchange nickname information between Level 1 
and Level 2; otherwise, forwarding paths inward or outward will not 
be calculated. For this purpose, border RBridges need to fabricate 
nickname announcements. Sub-TLVs used for such announcements are 
specified as follows. 


Besides its own nickname(s), a border RBridge MUST announce, in its 
area, the ownership of all external nicknames that are reachable from 
this border RBridge. These external nicknames include nicknames used 
in other unique nickname areas and nicknames in Level 2. Non-border 
RBridge nicknames within aggregated nickname areas are excluded. 
Also, a border RBridge MUST announce, in Level 2, the ownership of 
all nicknames within its area. From listening to these Level 2 
announcements, border RBridges can figure out the nicknames used by 
other areas. 


RBridges in the TRILL base protocol use the Nickname Sub-TLV as 
specified in Section 2.3.2 of [RFC7176] to announce the ownership of 
nicknames. However, it becomes uneconomic to use this Sub-TLV to 
announce a mass of internal/external nicknames. To address this 
issue, border RBridges SHOULD make use of the NickBlockFlags 
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APPsub-TLV to advertise into the Level 1 area the inclusive range of 
nicknames that are or are not available for self allocation by the 
Level 1 RBridges in that area. Its structure is as follows: 


Zhang, 


OR E22 Bs AB mo 6 OP 800 Ghee Ta AD TS) LAS AS 
$--4--4--4--4--4--4+--4--4+--4+--4+--4+--4+--4--4+--4--+ 


| Type = 24 
+—--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
| Length 
+—--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
| OK | RESV | 


+—--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
| Nickname Block 1 | 
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
E E NE OA E E ES E 
| Nickname Block K 

+—-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 


Type: 24 (TRILL NickBlockFlags) 
Length: 2 + 4*K, where K is the number of nickname blocks. 
OK: 


- When this bit is set to 1, the blocks of nicknames in this 
APPsub-TLV are associated to the border RBridge’s attached 
Level 1 area. The APPsub-TLV will be advertised in both 
Level 1 and Level 2. For nicknames that fall in the ranges 
of the nickname blocks, RBridges of Level 2 always route to 
the originating border RBridge, just as if this border 
RBridge owns these nicknames. 


- When this bit is set to 0, it indicates that the nicknames 
covered by the nickname blocks are being used in Level 2 or 
other areas so that they are not available for use in the 
border RBridge’s attached Level 1 area. The APPsub-TLV will 
be advertised into Level 1 only. For nicknames that fall in 
the ranges of the nickname blocks, RBridges of the area 
always route to the originating border RBridge, just as if 
this border RBridge owns these nicknames. For nicknames in 
these ranges, other RBridges will deem that they are owned by 
the originating border RBridge. The paths to nicknames that 
fall in these ranges will be calculated to reach the 
originating border RBridge. TRILL Data packets with egress 
nicknames that are neither in these ranges nor announced by 
any RBridge in the area MUST be discarded. 
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o RESV: reserved for future flag allocation. MUST be sent as 
zero and ignored on receipt. 


o Nickname Block: a starting and ending nickname as follows: 


+—--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
| starting nickname | 
+—--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
| ending nickname | 
+—--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 


Nickname Sub-TLV as specified in Section 2.3.2 of [RFC7176] is still 
allowed to be used, given the above NickBlockFlags APPsub-TLV is 
being used. 


There might be multiple border RBridges connected to the same area. 
Each border RBridge may advertise a subset of the entire 
internal/external nickname space in order to realize load balance. 
However, optimization of such load balance is an implementation issue 
and is outside the scope of this document. 


As specified in Section 4.2.6 of [RFC6325], multiple border RBridges 
may claim the same nicknames outwardly and/or inwardly. Other 
RBridges add those nicknames as if they are attached to all of those 
border RBridges. 


4.4. Capability Indication 


All border RBridges MUST understand the NickBlockFlags APPsub-TLV. 
Non-border RBridges in an area should understand the NickBlockFlags 
APPsub-TLV. If an RBridge within an area understands the 
NickBlockFlags APPsub-TLV, it MUST indicate this capability by 
announcing it in its TRILL-VER Sub-TLV. (See Section 7.) 


If there are RBridges that do not understand the NickBlockFlags 
APPsub-TLV, border RBridges of the area MUST also use the traditional 
Nickname Sub-TLV [RFC7176] to announce into the area those nicknames 
covered by the nickname blocks of the NickBlockFlags APPsub-TLV whose 
OK is 0. The available range of nicknames for this area should be 
configured on these traditional RBridges. 


5. Mix with Aggregated Nickname Areas 


The design of TRILL multilevel allows a mixture of unique nickname 
areas and aggregated nickname areas (see Section 1.2 of [RFC8243]). 
Usage of nickname space MUST be planned so that nicknames used in any 
one unique nickname area and Level 2 are never used in any other 
areas, including unique nickname areas as well as aggregated nickname 
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areas. In other words, nickname reusage is merely allowed among 
aggregated nickname areas. 


Border RBridges of an aggregated area MUST announce nicknames heard 
from Level 2 into their area like just like a unique nickname border 
RBridge. However, these RBridges do not announce nicknames of their 
area into Level 2. 


Each border RBridge of the aggregated areas will appear on the global 
tree, as specified in Section 4.1, as a single node. The global 
trees for unique nickname areas span unique nickname areas and Level 
2 but never reach the inside of aggregated areas. 


6. Security Considerations 


Since TRILL multilevel uses the existing IS-IS multilevel facilities 
[IS-IS], flooding of control traffic for link-state information is 
automatically confined to a Level 1 area or to Level 2 (except for 
limited types of information that can be specifically flagged for 
wider flooding). This addresses the TRILL scalability issues as 
specified in Section 2 of [RFC8243], and also, except for the wider 
flooding case, this confines the scope of the effects of malicious 
events that could be communicated through the link state. However, 
due to the fact that unique nickname areas share a common nickname 
space, border RBridges still have to leak nickname information 
between levels. Such leaking means that nickname-related events in 
one area can affect other areas. 


For this purpose, border RBridges need to fabricate the nickname 
announcements as specified in Section 4.3. Malicious devices may 
also fake the NickBlockFlags APPsub-TLV to announce a range of 
nicknames. By doing this, the attacker can attract TRILL data 
packets that were originally sent to a bunch of other RBridges. For 
this reason, RBridges SHOULD be configured to use the IS-IS 
Authentication TLV (10) in the IS-IS PDUs, particularly those 
containing the NickBlockFlags APPsub-TLV, so that IS-IS security 
[RFC5310] can be used to authenticate those PDUs and discard them if 
they are forged. 


If border RBridges do not prune multi-destination distribution tree 
traffic in Data Labels that are configured to be area local, then 
traffic that should have been contained within an area might be 
wrongly delivered to end stations in that Data Label in other areas. 
That is, the Data Label would no longer be area local. This would 
generally violate security constraints that require traffic to be 
delivered only to end stations in that Data Label in a single area. 


For general TRILL Security Considerations, see [RFC6325]. 
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7. IANA Considerations 


IANA has registered a new flag bit under the "TRILL-VER Sub-TLV 
Capability Flags" registry. 


Description Reference 
Able to handle the RFC 8397 
NickBlockFlags 


APPsub-TLV 


IANA has assigned a new type for the NickBlockFlags APPsub-TLV from 
the range available below 256 and add the following entry to the 
"TRILL APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1" 
registry as follows: 
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